package com.mego.thought.combat;

/**
 * 技术人也要有一些产品思维。对于产品设计、需求分析，我们要学会“借鉴”，一定不要自己闷头想。一方面这样做很难想全面，另一方面从零开始设计也比较
 * 浪费时间。除此之外，我们还可以通过线框图和用户用例来细化业务流程，挖掘一些比较细节的、不容易想到的功能点。
 *
 * 我们前面讲到，继承可以解决代码重复问题。我们可以将公共的字段定义在父类中，让 VO、BO、Entity 都继承这个父类，各自只定义特有的字段。
 * 因为这里的继承层次很浅，也不复杂，所以使用继承并不会影响代码的可读性和可维护性。后期如果因为业务的需要，有些字段需要从父类移动到子类，
 * 或者从子类提取到父类，代码改起来也并不复杂。
 *
 * 最简单的转化方式是手动复制。自己写代码在两个对象之间，一个字段一个字段的赋值。但这样的做法显然是没有技术含量的低级劳动。Java 中提供了多种数据
 * 对象转化工具，比如 BeanUtils、Dozer 等，可以大大简化繁琐的对象转化工作。如果你是用其他编程语言来做开发，也可以借鉴 Java 这些工具类的设计
 * 思路，自己在项目中实现对象转化工具类。
 *
 * 前面我们也提到过，Entity 和 VO 的生命周期是有限的，都仅限在本层范围内。而对应的 Repository 层和 Controller 层也都不包含太多业务逻辑，
 * 所以也不会有太多代码随意修改数据，即便设计成贫血、定义每个字段的 set 方法，相对来说也是安全的。
 *
 *
 * 1. 为什么要分 MVC 三层开发？对于这个问题，我总结了以下 5 点原因。
 * 分层能起到代码复用的作用分层能起到隔离变化的作用分层能起到隔离关注点的作用分层能提高代码的可测试性分层能应对系统的复杂性
 *
 * 2.BO、VO、Entity 存在的意义是什么？
 * 从设计的角度来说，VO、BO、Entity 的设计思路并不违反 DRY 原则，为了分层清晰、减少耦合，多维护几个类的成本也并不是不能接受的。但是，如果你真
 * 的有代码洁癖，对于代码重复的问题，我们可以通过继承或者组合来解决。如何进行数据对象之间的转化？最简单的方式就是手动复制。当然，你也可以使用 Java
 * 中提供了数据对象转化工具，比如 BeanUtils、Dozer 等，可以大大简化繁琐的对象转化工作。尽管 VO、BO、Entity 的设计违背 OOP 的封装特性，有被
 * 随意修改的风险。但 Entity 和 VO 的生命周期是有限的，都仅限在本层范围内，相对来说是安全的。Service 层包含比较多的业务逻辑代码，所以 BO 就存
 * 在被任意修改的风险了。为了使用方便，我们只能做一些妥协，放弃 BO 的封装特性，由程序员自己来负责这些数据对象的不被错误使用。
 *
 * 3. 总结用到的设计原则和思想从表面上看，做业务开发可能并不是特别有技术挑战，但是实际上，如果你要做到知其然知其所以然，做到透彻理解、真的懂，
 * 并不是件容易的事情。深挖一下，你会发现这其中还是蕴含了很多设计原则、思想和模式的。
 *
 *
 * 对于稍微复杂系统的开发，很多人觉得不知从何开始。我个人喜欢借鉴 TDD（测试驱动开发）和 Prototype（最小原型）的思想，先聚焦于一个简单的应用场景，
 * 基于此设计实现一个简单的原型。尽管这个最小原型系统在功能和非功能特性上都不完善，但它能够看得见、摸得着，比较具体、不抽象，能够很有效地帮助我缕
 * 清更复杂的设计思路，是迭代设计的基础。
 *
 *
 * 对于非业务通用框架的开发，我们在做需求分析的时候，除了功能性需求分析之外，还需要考虑框架的非功能性需求。
 * 比如，框架的易用性、性能、扩展性、容错性、通用性等。对于复杂框架的设计，很多人往往觉得无从下手。今天我们分享了几个小技巧，
 * 其中包括：画产品线框图、聚焦简单应用场景、设计实现最小原型、画系统设计图等。这些方法的目的都是为了让问题简化、具体、明确，提供一个迭代设计开发
 * 的基础，逐步推进。实际上，不仅仅是软件设计开发，不管做任何事情，如果我们总是等到所有的东西都想好了再开始，那这件事情可能永远都开始不了。
 * 有句老话讲：万事开头难，所以，先迈出第一步很重要。
 */
public class Main {
}
